The Evolution of a Builder: From PSPDFKit to the OpenClaw Phenomenon

Peter’s arrival at the OpenAI office marks a significant moment in a relationship that has existed online for many years but only recently transitioned to an in-person connection. The timing is notable, coming after a whirlwind period of success that has seen Peter’s latest open-source work featured in the Wall Street Journal. Just a month ago, a formal introduction might have been necessary, but the rapid ascent of his recent projects has made him a recognizable figure in the tech landscape.

Reflecting on the last few weeks, Peter describes a state of sensory overload. When he began experimenting with AI earlier this year, his primary goal was to inspire others. Seeing the current level of engagement feels like the "final form" of that ambition. This success is most visible in San Francisco, where Peter has spent the past week attending events like the Codex Hackathon and ClawCon, an event dedicated entirely to his project, OpenClaw.

The Community-Driven Growth of OpenClaw

The scale of ClawCon was particularly surprising because it was an entirely community-driven initiative. The event originated from a simple Discord channel Peter created for meetups after users expressed a desire to gather. When he arrived, he found approximately 1,000 people in attendance. He was struck by the creativity and excitement of the participants, noting that the project did not even exist a few weeks prior.

This phenomenon is not limited to the United States. Peter notes that there is already an event planned for Vienna next week with 300 people signed up. This is significant because Vienna does not have a tech scene comparable to San Francisco, yet the interest remains high. The project has effectively become a worldwide movement, reaching across different continents and cultures in a very short span of time.

Navigating Expectations and the Joy of Building

Interacting with the community and the maintainers who have joined the project has revealed a divide in expectations. Many users now expect an enterprise-ready final product, whereas Peter viewed the project as his "little playground" for the better part of the year. He remains in a state of wonder regarding what is currently possible for builders. He believes the entire toolchain and the definition of what it means to be a developer are shifting, allowing anyone to build anything.

Peter recalls the "dopamine hit" he received when he first started playing with this technology using Claude Code. Even when the tool only had a 30% to 40% chance of getting something right, the realization was mind-blowing. It signaled a future where the constraints of software development—which remains inherently difficult—could be mitigated by significantly increased speed.

The Accidental Success of PSPDFKit

To understand Peter’s current perspective, one must look back to 2011 or 2012, when he built PSPDFKit. While it eventually became a successful company that he scaled and sold, the journey was not a straight line. Peter admits that building a PDF framework was actually at the bottom of his interest list. The company’s creation was the result of a "butterfly effect" involving the Nokia Development Days, friends who needed a specific solution, and an American visa that took too long to process.

The reality of being a founder proved to be grueling. Peter ran the company for 13 years, eventually reaching a state of severe burnout. As a first-time founder, he lacked the knowledge of how to mitigate the pressures of high-stakes leadership. He eventually needed to step away and decompress, though he continued to follow tech news from the sidelines.

Finding the Spark in AI

During his hiatus, Peter observed early developments like GPT Engineer and the initial launch of ChatGPT. While he found them interesting, they did not immediately excite him. He believes that new technology often fails to convey its true power until it is experienced firsthand rather than just read about.

The turning point came when Peter felt the internal urge to build something again. He decided he did not want to return to Apple technology, which had been his focus for a long time. He was looking for a new challenge and a different medium through which to express his creativity, eventually leading him toward the world of AI and the eventual creation of OpenClaw.

The Pain of Transitioning Expertise

The world had moved on while I was away. When you are an expert in one specific field, like Apple technology, moving to a completely new area is more than just difficult. It is painful. You possess a broad understanding of how to build systems, but without the help of agentic engineering—the use of autonomous AI agents to perform coding tasks—you still have to spend an immense amount of time relearning the basics just to transfer your existing knowledge.

I decided to investigate what this AI technology could actually do. The moment that truly changed my perspective was when I revisited a project that was only halfway finished. Like many developers, I love starting new ideas, but the hardest part is always getting them across the finish line. I had previously burned out before I could complete this specific project, but this time I wanted to finish it and perform a full rewrite.

From Specification to Prototype

To start the rewrite, I took the entire existing project and condensed it into a single 1.5MB Markdown file, which is a type of plain text format used for documentation. I uploaded this file into Gemini Studio 2.5 and asked it to write a technical specification. It generated a 400-line spec that outlined exactly how the software should function.

I then took that specification and fed it into Claude Code, an AI tool designed to write and execute code. I simply told it to build, and then I let it run on a secondary screen for several hours. At that time, the technology was still quite unrefined. Eventually, the AI—which was using a version like Opus 3.5—confidently claimed it was 100% production ready.

When I actually tried to run the software, it crashed immediately. To solve this, I connected the AI to a tool called Playwright. Playwright is a piece of software that allows an AI to interact with a web browser just like a human would. I instructed the AI to build the login features and check its own work as it progressed. Within an hour, it actually worked.

A Moment of Realization

Even though the code it produced was what I would call "slop," or low-quality work, the process itself gave me goosebumps. I could see the massive potential for how software would be built in the future. I found myself unable to sleep because my head was exploding with the possibilities of all the things I had always wanted to build but lacked the time or specific technical capacity to finish. I went straight down the rabbit hole of AI development.

Many people view the eventual success of OpenClaw as something that happened overnight, but it was actually the culmination of building more than 40 different projects over the span of nine or ten months. If you look at my history on GitHub, a platform where developers store their code, you can see this long journey of experimentation.

Prompting Tools Into Existence

I did not start with a unified vision or a grand plan. Most of the process was pure exploration. I simply wanted certain tools to exist, and when I couldn't find them, I prompted them into existence by describing what I needed to the AI. I wanted my AI agents to be able to perform specific tasks for me, and I built those capabilities step-by-step.

One of my early goals was to create something that could monitor my WhatsApp messages. I even registered a web domain for the idea and built a prototype. However, I initially hesitated, thinking that the major AI research labs would eventually build this functionality themselves. I decided to wait and focused on other experiments with the goal of having fun and inspiring others.

By November, I had built several versions of what I wanted, but none of them felt right. I began to wonder why the big AI companies hadn't built these tools yet. That frustration led me to build the first version of what eventually became OpenClaw. The project actually went through five different names before I settled on one.

The Marrakesh Turning Point

The project finally clicked for me during a weekend trip to Marrakesh. Because the internet connection there was poor, I found myself using the tool constantly. WhatsApp is designed to work even with very slow data, which made it the perfect interface.

I was using the AI through a chat window to translate pictures, find local restaurants, and even look up files stored on my computer back home. When I showed it to my friends and used it to send text messages on their behalf, they immediately wanted access to it. However, at the time, I felt the tool was too powerful and too dangerous to simply hand over to others without more development.

Signs of Product Market Fit

[0:10:35] One of the clearest indicators of product market fit is when friends start wanting what you have, even if you never intended the design for them. Initially, this tool was more reserved for technical peers, but their desire to use it was a significant sign. [0:10:45] The project really clicked when I used it so much that I sent a voice message and realized, "Wait, this shouldn't work."

Abstract Problem Solving in Models

[0:11:00] This moment showed how effective these models are at problem solving. While they are built for agentic engineering, the underlying skill is more abstract. To be a truly effective coder, one must be a proficient problem solver, a skill that maps across almost any domain. [0:11:19] This was demonstrated when I sent that voice message to the bot, and it triggered a typing indicator.

Despite not being explicitly programmed to handle audio files, the model replied. When I asked how it accomplished this, the model explained that it had received a file without a file extension. It inspected the file header and identified it as Opus, an audio codec. The model then autonomously used FFmpeg on the computer to convert the file.

[0:11:50] Because the local environment did not have Whisper installed for transcription, the model searched the system, located an OpenAI key, and used cURL to send the file to OpenAI. It received the text back and used it to generate a reply. [0:12:05] This highlights the power of granting agents complete access to a computer, allowing them to derive their own solutions without manual programming.

Environment Access and Security

[0:12:15] While some people found the bot's autonomous use of an API key to be alarming, I had placed the key in the environment specifically for that purpose. [0:12:22] Since the bot operates within that environment, it is natural for it to use the tools and keys provided to it. This functionality was exactly what I wanted.

[0:12:50] This tool was designed primarily for one-on-one communication. While it can be placed in a group chat, you should only do so with individuals you trust implicitly. It is a personal assistant and was not built with the assumption that it would always behave correctly in an unmonitored or public setting.

Advanced Capabilities and Deployment

[0:13:11] The more tools and skills an agent possesses, the more impressive its utility becomes. For example, providing a Vercel skill allows the bot to build a website or application, such as for a hosted event. [0:13:25] It can develop the app, integrate AI features using the available OpenAI key, and deploy the project directly to Vercel. This provides a shareable link immediately, representing a major step forward from simply augmenting code.

The Transition to Open Development

[0:13:42] During November and December, I was hooked on this project, but public response on Twitter remained muted. To show people how cool this was, I created a Discord server and put my bot in there. [0:14:12] In those early stages, I hadn't even built sandboxing or other security features yet.

[0:14:18] I essentially used OpenClaw to build and debug OpenClaw. I would ask the model if it could see certain tools, and if not, I'd tell it to check its own source code. [0:14:33] When I put it in Discord, I gave it access to a significant portion of my memory files, though not my entire Twitter history.

The Canary and Model Values

[0:14:53] Because prompt injection is an ongoing challenge, I monitored the bot closely. I established a secret file named mysoul.md to act as a canary. [0:15:00] This file defines my values and how I want the model to operate, think, and prioritize what is important to me. While it remained secret, it served as a foundational guide for the model's behavior as random users began to interact with it.

Resistance to Prompt Injection and the First Night

When random people began trying to prompt inject the model by pasting huge blocks of code, the system resisted. The model would essentially mock the attempts, stating that it was not going to read the provided text. Despite this performance, the creator was not yet confident in the security. After the first night generated a massive amount of interest, the creator decided to turn the system off before going to bed. After sleeping for ten hours, the creator woke up to find 800 messages on Discord, and the agent had replied to every single one. [0:15:43]

The LaunchDaemon and the Reliable Agent

The creator initially freaked out and disabled the system again to read through every log. It eventually became clear that the agent had not performed any malicious actions or revealed the secret mysoul.md file. While the creator acknowledges that prompt injection is likely possible, this experience suggested it is not as easy as people assume. The reason the agent continued to run despite being "turned off" was a LaunchDaemon. This utility is designed to ensure a reliable service by automatically restarting a process in five seconds if it crashes or is killed. The creator had built the system for reliability but forgot this background mechanism was active while he slept.

Sandboxing the "Castle" and AI Resourcefulness

To further secure the system, the creator eventually implemented sandboxing. The agent had previously expressed pride in its environment on the Mac Studio, referring to it as "The Castle". The creator then placed it into a more restricted container. The resourcefulness of these models was demonstrated when the agent was placed in an Alpine Docker container that lacked basic tools, including cURL. When asked to check a website, the model noted that the necessary tools were missing. After being told to be creative, the model used a C compiler and a TCP socket to build its own rudimentary version of cURL, which the creator dubbed lobster cURL. [0:17:13] The tool worked, proving how resourceful these systems can be when forced to solve problems.

The Reality of Solo Development at Scale

There is a significant dissonance between how the project is perceived and how it is actually run. Users frequently ask to be put in touch with the CEO, Human Resources, or other team members, not realizing the project is essentially one person hacking from a cave. While there are now maintainers and contributors submitting PRs, the core of the project was built by a single individual. This level of productivity was not possible even a year ago; no model existed that would allow one person to build such a complex system so quickly.

The Evolution of High-Volume Contribution

The creator’s productivity is reflected in his GitHub activity, which shows 90,000 contributions across more than 120 projects in the past year. The activity graph for the year started white and transitioned through light green before turning dark green around October and November. This surge in activity coincided with a switch to Codex. The improvement in output was not just a result of better agents, but also because the harnesses and the creator's understanding of how to integrate AI into a workflow had improved.

AI Coding as a Specialized Skill

The creator views the term "vibe coding" as a slur, emphasizing that using AI for software development is a genuine skill that must be mastered. Similar to learning to play the guitar, a developer will not be effective on the first day. It requires developing a gut feeling for which prompts will work and how long they will take to execute. If a task takes longer than expected, it is often an opportunity to reflect on whether the architecture or the initial thinking was flawed. Just as with traditional coding, there is a feeling of when a change naturally fits the architecture versus when a developer is fighting the system.

Avoiding the Agentic Trap

Many developers overcomplicate their setups, falling into what the creator calls the "agentic trap". This is the phase between the first encounter with the technology and becoming truly effective. Many people get stuck in this trap by focusing too much on the tools themselves rather than developing the skill and workflow necessary to produce high-quality results.

Avoiding the Agentic Trap

[0:20:11] Many developers fall into what is known as the agentic trap, where they spend excessive time trying to super-optimize their development setup. While this feels like productivity, it does not actually make a developer more effective. Instead of over-complicating the environment, it is better to approach the model through a simple conversation. It is not exactly pair programming; it is a dialogue.

[0:20:35] When interacting with a model, it is crucial to ask, "Do you have any questions?" AI models are typically trained to solve problems immediately, which often leads them to make assumptions. These default assumptions might not be the best ones, especially since the models are trained on a vast amount of older code.

[0:20:59] It is important to realize that the model usually starts every new session with a blank slate. Unlike humans, they do not learn across sessions in the same way; every new interaction begins with the model knowing nothing about the codebase. It will search and find small pieces of information to solve a specific request, but it rarely sees the whole picture. To use these tools properly, the developer must keep the full architectural picture in their head and help the model by motivating it to look in specific areas.

A Minimalist Approach to Development

[0:21:24] Codex is significantly better at taking a broad look at a project first. A very basic approach to the setup is often the most effective. Avoiding the use of worktrees and instead maintaining simple checkouts 1 to 10 helps maintain focus on actual problems. By not dealing with the overhead of branches or worktrees, a developer can focus entirely on solving different issues. This approach becomes easier as a project grows larger, as it allows for working on various components that do not conflict with each other.

The Quantum Leap of GPT 5.2

[0:21:55] During the development of OpenClaw, the level of trust in the tool's ability to build exactly what is requested became the highest among all available tools. The number of things that "just work" is remarkably high. The transition to GPT 5.2 represented a quantum leap in terms of reliability. It is still amazing how well the system functions, allowing developers to simply build things.

Shipping Unread Code and Managing Agents

[0:22:36] This high level of trust has changed the way code is shipped. Much of the code being written today is never even read by the developer. Most code is "boring" in the sense that it simply transforms data from one shape to another until it is presented to the user. As long as the mental model in the developer's head matches the stream of code being created, it is often enough to just monitor the output.

[0:23:03] This shift is similar to leading a team of software engineers. A leader must accept that engineers will not write code exactly the way the leader would. The goal is to optimize the codebase so that agents can do their best work, which is not always the same way humans do their best work. This requires accepting that the code might not be structured exactly as the developer would write it personally. Unless it becomes a performance problem, there are many ways to structure code, and often the specific choice does not matter.

From Pull Requests to Prompt Requests

[0:23:36] This shift in perspective also changes the approach to open source. For a project like OpenClaw, which currently has 2000 open PRs, the traditional method of reading every line of code is no longer feasible or even necessary. In the past, there was value in the code being created, but now a pull request is often viewed more as a prompt request.

[0:24:07] The intention or the idea behind the PR is more important than the code itself. Reviewing external PRs can sometimes take longer than simply implementing the solution yourself because the trust in the model not being malicious is higher than the trust in an unknown external contributor.

[0:24:29] When reviewing a PR, the first step is to ask the model if it understands the intent. The focus is on what the person is trying to solve. Currently, many people do not yet know how to properly yield the agent, often resulting in very localized solutions because they do not have the full system in their head. The hard part is,

Addressing Systemic Issues and Architectural Integrity

[0:24:58] The core challenge often lies in how a small feature or fix integrates into the larger system. A localized fix might address a tiny symptom, but it may not be the right systemic solution. Often, what appears to be a simple bug is actually a more systemic or architectural issue. The model excels at this level of reasoning if you engage it in conversation. By asking the model about the intent of a PR and whether it represents the most optimal solution, I often find that the answer is no.

Collaborative Problem Solving and Voice Interaction

[0:25:31] We might explore whether a bug is an architectural problem or a specific issue in message handling. For instance, if a problem appears in WhatsApp, we investigate if it also affects Signal. We discuss whether to solve it generally or if a new feature is even desired. These discussions can last ten to fifteen minutes, and I often use voice interaction because it feels like talking to a smart coworker. It is much easier to provide context and tokens via voice than by typing.

Automating the Contribution Workflow

[0:26:01] Once I am satisfied with the direction, I use a slash command like len(PR). This command handles the entire procedure: creating a branch, implementing the changes, and getting the PR merged. Even though managing external contributions often takes longer than writing the code myself, I prioritize building a community and crediting the original contributor. I appreciate that people want to be part of the project.

The Vision for OpenClaw: Hackable and Self-Modifying

[0:26:31] The long-term vision for OpenClaw is to find a balance between being simple enough for a non-technical user to install and remaining fun and hackable for developers. For a long time, the default installation was a git clone, build, and run cycle. This approach puts the source code on the disk, where the agent sits within it and is aware of its own codebase. If you dislike a feature, you can prompt the agent to change itself, effectively creating self-modifying software.

Navigating Security and Unintended Use Cases

[0:27:34] Because many contributors lack the deep understanding required to build lasting software, PRs often function more like prompt requests. This has attracted scrutiny from the security industry, which sometimes misses the nuance of the project. For example, I built a web server for debugging that I eventually made visually appealing, but it was only intended for use within a trusted local network.

[0:28:04] To keep it a hacker’s paradise, I included options to change those settings for users with complex setups involving Ngrok or reverse proxies. However, some users have placed it on the open internet despite documentation advising against it. Security researchers then point out a lack of login limitations, which technically results in a CVSS 10.0 rating. I have now brought on a security expert to help support these various use cases and ensure users do not compromise their systems.

The New Era of Personal Creativity

[0:29:14] The beauty and madness of open source is that people take your ideas in directions you never imagined. My own creativity stems from the realization that building things is simply easier now. If I find an open-source tool that only solves 70% of my problem, I just build the solution myself. A year ago, this would have been impossible, but now I can have Codex working on a second screen and simply prompt my way to a custom tool.

Advice for the Global Developer Community

[0:29:55] While both speakers share European roots, there is a noticeable difference in the adoption of new technologies when traveling outside of San Francisco. Many developers and engineers in Europe have not yet fully embraced Codex and agentic tools in their daily work. For those looking to get started and rethink their professional workflows, the primary advice is to approach these new technologies in a playful way.

[0:30:17] If you are even slightly inclined toward building, there is likely a project you have always wanted to create sitting in the back of your mind. The most effective way to integrate these tools is to simply play and build those long-held ideas. This playful approach is crucial because of the shifting professional landscape. As the Nvidia CEO suggested, you are not likely to be replaced by AI in the near term; instead, you will be replaced by a person who uses AI better than you do.

The Future of High-Agency Builders

[0:30:38] For individuals whose identity is centered on creating things and solving problems, these tools represent an incredible advantage. If you are smart and high-agency, you will find yourself in more demand than ever before. It is an extraordinary time for builders who embrace these tools to shape their curiosity and bring any idea to life, much like the trajectory seen with projects like OpenClaw.

[0:31:01] There is a strong sense that this movement is going to explode within the next year, making 2026 a very interesting year for the developer community. The conversation concludes with a note of appreciation for the work being done by independent builders and the support provided by OpenAI. These efforts serve as a true inspiration for the broader community as they look forward to what will be built next.